• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The invention relates to a method for the secure management of an electronic ticket (4) stored in a mobile terminal (T) to which a security element (C_SE, SIM) is associated. The ticket is provided to access a service via an access control device (B). The ticket comprises: ○ an unsecured part (4a) comprising the identification of a service (SID) ○ and a secret part (4b, 4c) encrypted by a first key (K_SE) known to the security element (C_SE ); said secret portion (4b, 4c) comprises at least one second key (4c, K_TO). The method is characterized in that it comprises the following steps in the mobile terminal (T): - transmission (E3) to the security element (C_SE) of the second encrypted key (K_TO) and at least one piece of data verification (4b, random); receiving (E4) at least one verification datum (4b, random) encrypted by the security element (C_SE); - Transmission (E4) of at least one verification data item (4b, random) encrypted to the access control device (B).
    公开号:FR3037754A1
    申请号:FR1555723
    申请日:2015-06-22
    公开日:2016-12-23
    发明作者:Jean-Luck Patrick Grimault；Franck Grupeli；Vincent Boudier
    申请人:Orange SA；
    IPC主号:
    专利说明:

    [0001] Secure management of electronic tokens in a mobile phone. TECHNICAL FIELD The invention relates to the general field of the dematerialization of the titles of ownership otherwise known under the name of "electronic tokens", or "electronic tickets" and more particularly to the field of application in which an electronic token is intended to be stored in a mobile terminal adapted to restore said token to allow the user to access a property or more generally to a service. It finds a preferred application, but not limited to, in applications for which the mobile terminal restores the electronic token using a near field communication technique.
    [0002] State of the art "Near field" communication techniques are developing widely; the most used of these technologies for mobile telephony is that known by the acronym NFC (in English "Near Field Communication"). It is recalled that "NFC" communications, based mainly on the International Standard Organization (ISO) 14443, use wireless technologies to allow information to be exchanged between two peripherals distant from a short distance, typically less than ten centimeters. By "near field" is meant in the following primarily a NFC type technology, but it can be replaced by another type of RFID proximity technology (short-range radio technology according to English Radio Frequency IDentecation) , Zigbee (low power wireless radio technology based on the IEEE 802.15.4 standard), Bluetooth, infra-red, etc. It has already been demonstrated the feasibility of electronic chip or electronic ticket dematerialization services using contactless technology. Subsequently, the terms "token" or "ticket" for "electronic token" or "electronic ticket" will be used interchangeably. In particular, we know of transport services in which public transport users use a dedicated application of their mobile terminal to buy electronic tokens and to validate their token at the entrance of the bus or tram by approaching their mobile terminal with a device. access control capable of communicating with the mobile terminal, or more accurately with a security element of the mobile terminal, by means of communication in the near field, 3037754 2 to obtain the electronic token to verify the validity. Subsequently, such a user is called a "user", which means the user of the mobile terminal, who is also the client of the token provider. By "security element" is meant here a data storage and manipulation element to guarantee a user of the mobile terminal a high security since the data stored in the security element is not accessible to a non-user. authorized. In our context, the implementation of a security element allows the service concerned to ensure the validity of the token presented to access the service. This security element may for example be constituted by a SIM card (of the English Subscriber Identity Module) used in mobile telephony to store the subscriber-specific information of a mobile network and the user's applications. of its operator or in certain cases of third parties. This security element can still be a secure SD card-type removable medium or a security element integrated in the terminal 15 ("Embedded Secure Element") or a secure mode of the terminal, through the use of security technology integrated in the processor and its peripheral components (for example the "TrustZone" technology, registered trademark of the ARM company) In the case of a terminal supporting Android-type applications (it is recalled that an Android application is a mobile application 20 specifically developed for mobile terminals using the Android operating system developed by the Google company), near field applications can also run in the Android terminal itself (from version 4.4. "KitKat") thanks to the "HCE" ("Host Card Emulation") technology, the terms "security element" and "card 25 SI" will be used interchangeably M "Access control device" means a physical device comprising a reading module in the near field, capable of acquiring knowledge of the contents of the electronic token and verifying its validity, in association with a verification server ( the date of validity of the token, etc.) and authentication (of the security element associated with the user of the mobile terminal). Subsequently, the terms "access control device" and "reader" will be used interchangeably. By "token validation", we mean all two operations, namely the verification of the token and the authentication of the security element. Another example is the "M-35 Stadium" experiment in Caen, France, which showed the integration of contactless technology throughout the course of an audience in a stage: acquisition and dematerialization of electronic tokens on mobile terminals, control of electronic tokens 3037754 and reading of interactive labels in the stadium, etc. Users of such a system previously load a token using a mobile application of their mobile terminal equipped with contactless technology. The data thus loaded, relating to the token, are stored and managed in a security element associated with the mobile terminal, in this case the user's SIM card, and then checked at the entrance of the stadium by means of a terminal. control. In all these examples, it is necessary that the remote server which delivers the tickets has the secret key of the corresponding secure application contained in the security element associated with the mobile. For example, the "theater" accessed by the user (as well as the service that provided the theater tickets to the users) must know the secret key of the service stored in the security element. This is a constraint, since it requires any new service to have own secret key in the security element.
    [0003] The invention proposes a system for controlling access to a service by the user of a mobile terminal equipped with a near-field communication function and a security element, by validating an electronic token, which does not have such disadvantages.
    [0004] According to a first functional aspect, the subject of the invention is a method of securely managing an electronic ticket stored in a mobile terminal with which a security element is associated, the ticket comprising an unseen part comprising the identification of a service and a secret portion encrypted by a first known key of the security element, comprising at least a second key, the ticket being provided to access the service via an access control device, the method being characterized in that it comprises the following steps in the mobile terminal: transmission to the security element of the second encrypted key and at least one verification data item; receiving at least one verification data encrypted by the security element; Transmitting at least one encrypted verification data to the access control device.
    [0005] Advantageously according to the invention, it is not necessary for a third party entity to possess the secret key of the corresponding secure application contained in the security element associated with the mobile. Indeed, the security element itself, for example a SIM card, is capable of decrypting the verification data corresponding to data encrypted by the first secret key and of re-encrypting the elements that it has just deciphered. using the key contained in the secret part of the token. In this way, the server issuing the tickets, and knowing the ticket key, failing to know that of the security element, is able to know that the ticket has been correctly deciphered by the right security element. It is therefore advantageously avoided the need to load a specific security application for each service and a service-specific key in the security element (application that should specifically manage tickets according to the service to be rendered, ie an application for transport, an application for payment, a third for shows, etc.), while retaining the advantages of the secure element, ie strong authentication by the security element which decrypts and then encrypts (or re-encrypts) the data without storing the ticket and without having to analyze the data. It is furthermore advantageous, according to this aspect, to store the tickets 20 in the mobile terminal and to have them processed by the security element when necessary because the tickets can be bulky (in number of bytes) and occupy a space important memory in the security element.
    [0006] According to a first particular embodiment of this aspect, the secret part of the ticket comprises at least one secret datum distinct from the second key and a verification datum transmitted to the security element comprises at least this secret datum. Advantageously according to this embodiment, said mode "without random", a secret data contained in the ticket, any, is used as verification data to be decrypted (by the first key) and then re-encrypted (by the second key) by the security element, thus ensuring that we have to do the right security element, which validates the ticket.
    [0007] According to a second particular embodiment of this aspect, which may be implemented alternatively or cumulatively with the preceding one, a method as described above is characterized in that it further includes a step of 3037754. receiving a hazard from the access control device and in that verification data transmitted to the security element comprises at least the hazard. Advantageously according to this embodiment, said mode "with random", the random number, or random number, received from the server (via the access control device) is encrypted by the SIM card using the second key that she has just deciphered in the secret part, as a verification datum. The verification server is therefore able, upon receipt of the verification data, to decrypt the hazard that it has issued previously, and to find that it has been encrypted by the correct key associated with the good ticket. In this case, the transaction can be validated. The verification server also has the assurance that the decryption / encryption process has not been done in advance and picked up by a third party mobile. As described above, this embodiment may naturally be associated with the above, the verification data may then contain a secret data and a hazard, but this association is not necessary, the presence of one or the other other of these elements sufficient for the validation of the operation. According to a second functional aspect, the subject of the invention is a method of verifying an electronic ticket stored in a mobile terminal with which a security element is associated, the ticket comprising an unsecured part comprising the identification of a service. and a secret portion encrypted by a first known key of the security element, said secret portion comprising at least a second key, the ticket being provided for accessing a service via an access control device, the method being characterized in it comprises the following 25 steps in the security element: reception from the mobile data including at least: o the second key of the secret part and o at least one verification data; decrypting the secret part using the first key; Encrypting a verification data received with the second decrypted key; - Transmission of encrypted verification data to the mobile. Advantageously according to this aspect, it is not necessary to store the tickets in the security element which simply decrypts using the first key and then encrypting with the second key the verification data which they are transmitted by the mobile. Indeed, the SIM card itself is able to decrypt the part encrypted by the first secret key and to encrypt the elements it has just decrypted or the hazard using the second key contained in the part. secret of the token. The security element in this context may advantageously be devoid of any means of communication with the outside, in particular not having itself a near-field communication capability. According to a third functional aspect, the subject of the invention is a method for generating an electronic ticket for a mobile terminal with which a security element is associated, the method comprising the following steps: generating an unseen part containing a security identification of a service; generating a secret portion having a second key; characterized in that the secret portion is encrypted by a first known key of the security element. Advantageously according to this aspect, a single key of the security element can be used for all services related to the ticket generator; so there can be several generators. On the other hand, the token issuer (ticket generator) does not know this key of the security element. According to a particular embodiment of this aspect, a method as described above is further characterized in that the second key is generated by the following steps: obtaining a master key; generating the second key from the master key and the unencrypted part of the token. Advantageously according to this embodiment, fields of the non-secret part of the token, for example the date of the show and a string of characters, serve the verification server to obtain the token key by a so-called "diversification" method based on on the knowledge of a mother key contained in the verification server. Such a method is well known to those skilled in the field of the manufacture of smart cards where the key to manufacture each card is generated from a master key (mother) and the serial number of the card. .
    [0008] The verification server is made simpler in that it does not need a token database and can be included in the control device locally, without access to the network.
    [0009] According to a material aspect, the invention also relates to a mobile terminal with which is associated a security element, able to manage a ticket, the ticket comprising an unseen part comprising the identification of a service and a secret part encrypted by a first known key of the security element, said secret portion comprising at least a second key, the ticket being provided to access the service via an access control device, the terminal being characterized in that it comprises the modules following: a transmission module to the security element of the second encrypted key and at least one verification data item; A module for receiving at least one datum of the security element; a module for transmitting at least one encrypted data item to the access control device. The term module may correspond to both a software component and a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subprograms, or more general to any element of a program capable of implementing a function or a set of functions as described for the modules concerned. In the same way, a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc.). According to another material aspect, the invention also relates to a security element associated with a mobile terminal able to make available to an access control device, via the mobile terminal, an electronic ticket stored in the mobile terminal, the ticket comprising a non-secret part comprising the identification of a service and a secret part encrypted by a first known key of the security element, said secret part comprising at least a second key, characterized in that it comprises the following modules: a module for receiving data from the mobile, comprising at least: o the second key of the secret part and o at least one verification data item; A module for decrypting the data received using the first known key of the security element; an encryption module of a data item received using the second decrypted key; a module for transmitting an encrypted verification data to the mobile. According to another material aspect, the invention also relates to a ticket generation entity able to generate tickets for a mobile terminal with which a security element is associated, characterized in that it comprises the following 15 modules: a module of generating an unseen portion including the identification of a service; a module for generating a secret part comprising a second key; A module for encrypting the secret part by a first known key of the security element. According to another material aspect, the invention also relates to a system for providing a secure dematerialized ticket service to the user of a mobile terminal, this system comprising: an entity for generating an electronic ticket according to the preceding description ; a mobile terminal according to the preceding description; a security element associated with the mobile terminal according to the preceding description. According to yet another material aspect, the invention also relates to a computer program adapted to be implemented in a mobile device for implementing the method of secure management of electronic tickets as defined above, the program comprising code instructions which, when the program is executed by a processor, performs the steps of the secure management method. According to yet another material aspect, the invention also relates to a computer program adapted to be implemented in a device for implementing the ticket verification method, when the latter is executed by a processor. According to yet another material aspect, the invention also relates to a computer program adapted to be implemented in a device for implementing the ticket generation method, when the latter is executed by a processor. These devices and computer programs have features and advantages similar to those previously described in connection with the methods of managing, checking and generating an electronic ticket. In yet another material aspect, the invention relates to a recording medium readable by a data processor on which is recorded a program comprising program code instructions for executing the steps of one of the methods. defined above. The invention will be better understood on reading the description which follows, given by way of example and with reference to the accompanying drawings.
    [0010] The figures: Figure 1 shows the general context of an embodiment of the invention. FIG. 2 represents an architecture of a mobile equipment equipped with a subscriber identity module and an NFC module, able to implement one embodiment of the invention. FIG. 3 represents the possible structure of an electronic token according to one embodiment of the invention. FIG. 4 represents a flowchart illustrating the various steps of the method according to one embodiment of the invention.
    [0011] DETAILED DESCRIPTION OF AN EMBODIMENT EXCHANGING THE INVENTION FIG. 1 corresponds to the general context of one embodiment of the invention; it is a question of controlling, by an access control device, or reader (B), dematerialized tokens stored on the mobile (T) of a user (1), with an authentication by the security element (C_SE) which is in this example a SIM card. In this embodiment of the invention, the mobile terminal (T) also has an NFC module (3) allowing the use of contactless communications between the mobile and the reader (B). The NFC capacity of the mobile is thus rendered, not by the security element (which has no near-field communication capability), but by the mobile itself, equipped with NFC capabilities (for example, the technology HCE on the Android system). The mobile can contain various applications including at least one for the management of tickets, which will be called APM (Mobile Application). The SIM card contains at least one generic application (APS) valid for all ticket management services. It is recalled that the uses 15 targeted by the invention are those for which the user has a token or ticket (4) with which he can prove to be in possession of a right of access to a service with limited validity on a specific date or during a defined period of time (for example, a transport subscription for the month of October 2014) or that can be verified when accessing the service (for example, access to a concert, a sports competition , etc.). In this embodiment, it is considered that the intended application is a ticketing application delivering concert chips. It is assumed here that the user has purchased an electronic token from a service provider, represented here by his generation and token checking server (7), located in the example in an Internet network (9). ; the token generated by the generation server (7) is transmitted to the server (5), also called trusted server, which can be for example a server of the network operator. The token (4) consists of: - an Unsecured Party (4a, PNS) including in particular the identity of the service, the public information of the token (name of the show, date and time, etc.) and optionally the number the token in this service; a secret part (4b, 4c), comprising: o the secret data (4b, DS) of the token, optional according to this so-called "with random" embodiment (as will be seen later, they can not be optional in other embodiments); for example, a secret data item may refer to technical elements specific to the token server, or a security key specific to the token (4c, K_TO) that is not optional. We will now, in support of Figure 1, illustrate the various stages of implementation of the service, from the generation of the ticket until validation at the level of the validation device (reader). The user controls according to this example his token (4) on the server of the service provider (7), with his mobile terminal (T), through a data connection of the mobile network extending in this example to the Internet, and receives its token on the mobile (T) in the form of SMS (acronym for Short Message 10 Service) or MMS (Multimedia Message Service). Alternatively, the token could be transmitted in response to an HTTP (Hyper Text Transport Protocol) command following the control phase of the ticket following the same protocol. According to yet another possibility, the user orders his token using another terminal (PC, tablet, etc.) and receives it on his mobile in the form of SMS or MMS. The Internet access network (Internet in which the service provider's server is located (7)) is here a mobile network, but other types of access networks would be possible, for example an ADSL network (control of the Internet). ticket on a PC and delivery on the mobile), a Wifi point (order and receipt of the ticket 20 on a mobile terminal or tablet), etc. In this embodiment, it is the trusted server (5) which transmits to the mobile phone of the user (T) the token (4) which he has previously encrypted the secret part (4b, 4c). Encryption is performed by means of a Security Element Security Key (SIM), denoted K_SE (for Key of Secure Element), known to the trusted server. In another embodiment, the trusted server (5) could perform the above encryption operations and return the result to the generation server (7) which would itself be responsible for transmitting the ticket (in the form of SMS, MMS, or HTTP response following the purchase phase of the ticket on mobile).
    [0012] Once delivered on the mobile, the token (4), the secret portion (4b, 4c) is encrypted (which is illustrated in Figure 1 by the black rectangle at the top of the ticket), is stored in the memory of the terminal (T); it can verify that it has received a new token through a mobile application terminal that is able to read the unseen part of the token (since it has not been encrypted) and display it. Typically, when the mobile terminal receives the token, for example in the form of SMS starting with a given identifier, the mobile application detects it. On request or automatically, the tokens stored on the mobile appear in the graphical interface that the mobile application for managing the tokens proposes to the user, and are usable if the conditions of validity are fulfilled (date, etc.). . Alternatively, the chips can be managed by several applications on the mobile (one for transportation, another for shows, etc.).
    [0013] According to one example, each displayed token is selectable by the user, for example by a touch of the finger on the touch screen of the mobile phone, and a dialog box can ask for a confirmation of the selection of the token. It should be noted that the electronic dematerialized tokens are not stored in the security element but on the mobile terminal. As will be seen later, when the user accesses the service, the security element serves only to ensure the confidentiality of the secret part of the token and the authentication of the user (by deciphering the encrypted subset of the token, then by encrypting some data, say validation data with the token key and authenticating the user at the same time).
    [0014] The security element (C_SE), in this case a SIM card, contains a secure application, also called an applet, which is installed on the SIM cards of the users of mobile terminals wishing to have access to the different services of dematerialized tokens. This is a unique app for all services and tokens. It is later called "Applet", or "Secure Application", or "APS". It can access the secret key (K_SE) located in the memory of the SIM card, which allows the SIM card, when the user access to the service, to ensure the confidentiality of the secret part of the token and to ensure the authentication of the user, by the method which will be described later. Subsequently, when the user approaches the access control device its mobile containing the ticket (T), an NFC communication is established between the reader and the NFC module (3) of the mobile terminal of the user.
    [0015] In this first embodiment "with random", the reader (B) furthermore dialogues with the server (7) for checking the tokens (which according to this example is the same as the one that generated the ticket, but could be independent ) and asks him for a hazard. This randomness is typically a random number chosen by the token verification server (7), which allows a malicious third party who is listening to no guess at a future hazard based on observation of the chips. past hazards. The terminal transmits to the mobile this hazard and the identity of the service.
    [0016] In a first variant, the mobile management application (APM) retrieves the token from a list of tokens thanks to its non-secret part (4a), selects the token (4) and transmits it to the applet of the card SIM with the hazard. In a second variant, only the encrypted part (Secret Part PS) of the token is transmitted to the SIM card with the hazard. The SIM card decrypts the secret data (4b, DS) if it exists and the key of the token (4c, K_TO) with the secret key (K_SE) and encrypts the secret data (if they exist) and the hazard using the token key (K_TO) that she has just deciphered; it then transmits the result of the operation to the mobile (T). The mobile assistant then the public part of the token result received from the SIM card before transmitting everything to the verification server via the reader. It will be understood that according to this embodiment of the invention, the secret data (DS, 4b) of the ticket are optional because the hazard alone constitutes a verification datum that can be validly encrypted by the SIM card. In the absence of randomness, on the other hand, according to another embodiment, at least one secret data is required on which to apply the encryption by the token key (K_TO). This key-token can indeed satisfactorily quantify itself. The sequence of steps being almost identical for the first (transfer of the complete ticket 20 to the security element with the hazard) and the second variant (transfer of the hazard and the secret part optionally including secret data and necessarily the key of the token) of this random embodiment, only the first variant is described below. The second embodiment will not be described explicitly, but it suffices, without any loss of generality, to replace the encryption of the hazard by the encryption of the secret data (DS) with the key of the token (K_TO) in order to benefit from the advantages of the 'invention. Naturally, the two embodiments can be combined (encryption of the random and secret data of the ticket by the key K_TO).
    [0017] In this embodiment, the random number encrypted by the SIM card and the non-secret part (4a, PNS) of the token are transmitted to the verification server via the mobile phone and the near-field reader (3). The non-secret portion (4a) of the token serves the verification server to determine the corresponding entry to the token in question in its database. The verification server then finds the token key. It can subsequently decrypt the token verification data (the hazard). If the randomness resulting from the decryption by the verification server is equal to the randomly issued 3037754 14 for this token, then he deduces that it was a token associated with the SIM of the token buyer and decreed that the token is valid for this session. The reader (B) waits for the response of the token verification phases (4) performed by the verification server. The reader may comprise a graphical interface, not shown, which enables it to display information intended for the bearer of the mobile terminal. For example, a "state" part indicates the state of the verification: the display indicates in green that the access is authorized, in gray what the user must do and in red any error occurred. If the response of the token verification phases performed by the verification server is positive, then the terminal responds positively to the request of the user, for example by opening a gate to let it pass. The terminal detects when the mobile terminal is no longer placed on the reader, and can then start a new check when a new terminal approaches.
    [0018] With reference to FIG. 2, a system comprises a terminal T able to communicate with a network (9) comprising a token provider (7) and to communicate with a reader (B) to perform the validation of an electronic token, And a security element (C_SE) adapted to be inserted into the terminal (T) and to perform decryption and encryption for the authentication. The terminal T is, for example, a mobile phone or a PDA (for "Personal Digital Assistant") or a tablet of the user.The terminal T conventionally comprises a processing unit, or "CPU" (for "Central 25 Processing Unit "), intended to load instructions in memory, to execute them, to perform operations, a set of memories M, including a volatile memory, or" ffli "(for" Random Access Memory ") used to execute instructions code, storing variables, etc. and a non-volatile memory, of the "ROM" type ("Read Only Memory"), or "EEPROM" (for "Electronically Erasable Programmable Read Only Memory") intended for contain persistent data used, for example, to store the electronic tickets and the ticket management application APM The terminal T also comprises: a first communication module MC1 able to communicate with the security element C_SE, via a communication interface (II). A second communication module MR, enabling communication, via a mobile communication network, with remote servers, for example with the trusted server (5) for receiving tokens via SMS, extended mobile communication network via the Internet (9) to the provider / ticket verifier (7) if the user buys his token from his mobile (in HTTP browsing mode). It is for example through this medium (mobile communication network extended via the Internet (9)) that the mobile terminal (T) receives the application APM (Application in Mobile) ticket management (according to our example, in concert ) loaded into a memory M of the mobile. a third contactless communication module (3), able to communicate the mobile with a nearby equipment via an NFC-type contactless link, for example the reader B located near the terminal T. Alternatively this link may use a other proximity communication technology (Bluetooth, Zig bee, DECT, etc.) The security element C_SE is in this example a "SIM card" but 15 could without loss of generality be a memory card hosting a secure element (SD card, Embeded Secure controler, etc.) or a specific memory area of the terminal as in the context of the HCE defined above. The security element C_SE, commonly used for mobile network authentication (in the case of the SIM card) has the function (in addition to the conventional function of ensuring the authentication of the subscriber for the connection to the mobile network). to implement, in the context of the present invention, the phases presented above. For this purpose, the SIM card has the secret key (K_SE) of its own. The security element C_SE comprises a first transmission / reception module MC1 'able to communicate with the terminal T via the communication interface Il. In this embodiment of the invention, the security element C_SE is a SIM card and conventionally comprises ROM type memories M 'containing in particular the operating system of the security element and programs implementing the security mechanisms. security, inter alia the network authentication algorithm, EEPROM memories permanently containing directories and data defined by the mobile standard (e, g GSM, UMTS, etc.), the authentication keys ( including the key K_SE), as well as specific applications also called applets running in a RAM type memory. FIG. 2 shows the common security applet (APS) used in the context of this invention for processing the electronic tokens according to the method described.
    [0019] In order to communicate with the SIM card, the application on the mobile uses according to this embodiment the SmartCard API according to the ETSI 102.221 recommendation. It makes it possible to open a communication channel with the APS application of the SIM card for sending the data (the token and optionally the random) and the reception of data (the token and optionally the hazard signed by the token key) as packets. Figure 3 shows the possible structure of an electronic token according to one embodiment of the invention. As mentioned above in support of Figure 1, it comprises - an unsecured part (4a, PNS) comprising for example: o the identity of the service (M1), e .g. "Concert tickets of the Rennes Opera" 15 o the public information of the token (M2): name of the show, date and time, etc. o Optionally, the number of the token in this service. o etc. secret data (4b, DS), optional, corresponding to the private data of the token; for example technical elements specific to the token server (price at which the token was purchased, etc.). Recall that if these data are optional in the first embodiment, called "mode with random" described in support of Figure 1, they are not in an embodiment without hazard, since in this case it 25 is necessary for the proper functioning of the invention that at least one secret data is decrypted and encrypted by the SIM card. a token-specific security key, the token key (4c, K_TO) constituting with the secret data (optional - depending on the embodiment) the secret part (PS) of the token.
    [0020] Figure 4 shows a kinematic of the exchanges between the different entities of the invention. It is assumed here that the prerequisites for obtaining the token, already described in support of FIG. 1, have been fulfilled during a step E0: the concert token (4) has been loaded onto the mobile (T ) of the user, who wishes to pass the terminal of the concert hall. A sequence of steps, transparent to the user, are then performed between the mobile (T) and its NFC module (3), the SIM card (C_SE), the terminal (B) and the verification server (7). ) At the request or automatically, the tokens stored on the mobile 5 appear in the graphical interface that the mobile application for managing the tokens proposes to the user, and are usable if the validity conditions are met. are completed (date, etc.). The desired token (4) is selectable by the user, for example by a finger pressure on the touch screen of the mobile phone, and a dialog box can ask for confirmation of the selection of the token.
    [0021] During a step El, the user (1) of the mobile service confirms the selection and approaches his mobile reader. During a corresponding step E31, the reader (B) opens a session with the server (7) for generating and / or verifying tokens and requests a random access to the server. This step may be optional, the absence of a hazard, however, rendering the service less reliable. Note also that if this step is optional, the secret data (DS, 4b) of the token are no longer optional. The reader (B) then requests the mobile, during a step E32, the token reading, providing the identity of the service (SID); at the same time it provides the random received from the server. During step E2, the mobile service (APM application) finds the correct token thanks to the non-secret part of the token which contains among others the identity of the service (SID). It transmits to the security element so-called verification data, which comprise, in this random embodiment, the secret part of the token 25 (secret data 4b optionally and key-token K TO in a mandatory manner) and randomness. According to one variant, the whole of the token (non-secret part and secret part) can be transmitted, this simplifying the mobile application (which no longer has to select the fields before sending to the security element) to the detriment of the security element 30 itself (it is necessary to benefit from more memory space in the security element and a more complex application since able to analyze the structure of the message to extract the different data). According to another embodiment "without risk", the hazard is not used but the secret part necessarily includes secret data (4b).
    [0022] It will be recalled that the security element (C_SE), for example a SIM card, contains a secure application, also called an applet (APS), which is installed on the security element of the users of mobile terminals wishing to have access to the devices. different services of dematerialized tokens. She can access the private key. K_SE of the user in the memory of the security element, which allows the latter to decrypt the encrypted subset of the token, to extract the second key, or key of the token (4c, K TO) , to then encrypt the DS Secret Data or the hazard with the key 5 of the token (4c, K TO), while simultaneously authenticating the SIM card with the token server (thanks to the encryption of the hazard or the Secret Data DS of the Secret Party). The applet of the security element therefore performs the following operations in this embodiment: E10: the card receives from the mobile the random and the secret part PS (4b, 4c); - E11: it decrypts with its key (K_SE) the encrypted part of the token corresponding to the secret part (4b, 4c) and containing at least the key of the token (K_TO, 4c); E12: it encrypts the Secret Data DS (according to the second embodiment) of the token or the random (according to the first embodiment) using the token key (4c, K_TO) that it comes from decipher. The data resulting from the encryption operation (encrypted result of the secret data DS of the token and the random) are retransmitted to the mobile during a step E13, then transmitted with the public part of the token by the mobile to the server of verification, via the NFC reader (steps E4 and E33). These different transmissions are noted in abbreviated form: PNS, [Alea + DS] K ro to signify the transmission of the non-secret part (PNS), then secret data (DS) as well as of the random number encrypted by the key. K_TO of the token. In the next step E41, the public part (4a, PNS) of the token, which is not encrypted, is used to determine the entry corresponding to the token in question in the database of the verification server. It has in fact kept in its database, during the generation of the token, an entry associating the non-secret part 30 of the token to the token. It extracts from this token the key token (4c, K_TO) that it had chosen itself during the generation of the token then uses this key to decipher the set that it has just received (the random number according to the first embodiment, the Secret Data DS according to the second embodiment or the set {Aléa and DS} encrypted according to the combined mode shown in Figure 4).
    [0023] According to the "randomized" embodiment, the randomization error of the verification server is compared in step E42 to that in the database; if the two random values are identical, he deduces that it was a token associated with the SIM of the token buyer and decreed that the token is valid for this session and means it to the terminal. Otherwise the step fails. Indeed, since it trusts the trusted server (for example the mobile operator, or the cultural channel that sold the token), the verification server knows that the correct token (containing at least the token key ( 4c, K_TO) encrypted by the correct key K_SE) was sent to the correct security element and only this element with the key K_SE could decrypt the token. This ensures both the validity of the token (thanks to the hazard and the key token 10) and the validity of the security element (thanks to the key of the security element) and therefore to the authenticity of the associated mobile carrier. According to another embodiment "without risk", it is the secret data of the token, mandatory in this case, that validate the transaction. It will be noted that the use of the system without risk to ensure the authentication of the SIM card (and therefore of its bearer) offers a lower level of security to the authentication since the verification server does not then have the assurance that the decryption / encryption process was not done in advance and picked up by a third party mobile. This mode without risk is however acceptable for access to shows for example, which require a lower level of security; it is not available for transport subscriptions. During a step E34, the reader (B), waiting for the response of the verification phases of the token (4) made by the verification server receives from it the authentication information (of the SIM card) and token validation. The reader may comprise a graphical interface, not shown, which enables it to display information intended for the bearer of the mobile terminal. For example, a "state" part indicates the state of the verification: the display of the terminal indicates in green that the access is authorized, in gray what the user must do and in red any error occurred. If the response of the authentication and token verification phases is positive, then the terminal responds positively to the request of the user, for example by opening a gate to let it pass. Afterwards, it detects when the mobile terminal is no longer on the NFC reader, and can then start a new check when a new terminal approaches.
    [0024] It goes without saying that the embodiment which has been described above has been given for information only and in no way limitative, and that many modifications can easily be made by those skilled in the art without depart from the scope of the invention. In particular, according to a variant of the embodiments presented above ("with random" and "without random" mode), fields of the non-secret part of the token (4a) are used by the verification server to obtain the token key by a diversification method based on the use of a mother key, contained in the verification server. In this case, the verification server does not need a token database and can be included in the reader (B); it can operate locally, without network access. In such a case, the verification server in the reader, when it receives the unsecured part (PNS) of the token and the secret data and / or the risk encrypted by the security element: uses the mother key that he has at his disposal and the ad hoc fields of the unsecured part of the token to regenerate the session key (the daughter key corresponding to the token key K_TO in the above description), he can then decrypt the encrypted verification data. which have been transmitted to him. If the verification data resulting from this decryption are equal to those previously issued, it deduces that it is a token associated with the security element of the token buyer and decrees that the token is valid.
    [0025] The invention may also apply to payment or money transfer services for which a token may represent a sum of money.
    权利要求:
    Claims (13)
    [0001]
    REVENDICATIONS1. Method for the secure management of an electronic ticket (4) stored in a mobile terminal (T) with which a security element (C_SE, SIM) is associated, the ticket (4) comprising an unsecured part (4a) comprising the identification a service (SID) and a secret part (4b, 4c) encrypted by a first key (K_SE) known from the security element (C_SE), said secret part (4b, 4c) comprising at least a second key ( 4c, K_TO), the ticket being provided to access the service via an access control device (B), the method being characterized in that it comprises the following steps in the mobile terminal (T): transmission (E3) the security element (C_SE) of the second encrypted key (K_TO) and at least one verification datum (4b, random); receiving (E4) at least one verification data (4b, random) encrypted by the security element (C_SE); transmission (E4) of at least one verification data (4b, random) encrypted to the access control device (B).
    [0002]
    2. A method for securely managing an electronic ticket (4) stored in a mobile terminal (T) according to claim 1, characterized in that the secret part (PS) of the ticket (4) comprises at least one secret data (DS , 4b) distinct from the second key (K_TO) and in that a verification data transmitted to the security element (C_ES, SIM) comprises at least this secret data (DS).
    [0003]
    3. A method for securely managing an electronic ticket (4) stored in a mobile terminal (T) according to claim 1, characterized in that it further comprises a step of receiving (E2) a random event from the access control device (B) and in that a verification data transmitted to the security element (C_ES, SIM) comprises at least the hazard.
    [0004]
    4. A method for verifying an electronic ticket (4) stored in a mobile terminal (T) to which a security element (C_SE, SIM) is associated, the ticket (4) comprising an unsecured part (4a) comprising the identification of a service (SID) and a secret part (4b, 4c) encrypted by a first key (K_SE) known from the security element (C_SE), said secret part (4b, 4c) comprising at least one second key (4c, K TO), the ticket being provided to access the service via an access control device (B), the method being characterized in that it comprises the following steps in the security element: receiving (E10) from the mobile (T) data comprising at least: o the second key (4c, K_TO) of the secret part (PS) and o at least one verification data (4b, DS); decrypting (E11) the secret portion (4b, 4c) using the first key (K_SE); encrypting (E12) a received verification data (4b, random) using the second decrypted key (K_TO); transmission (E13) of verification data (4b, random) encrypted to the mobile (T). 15
    [0005]
    5. A method for generating an electronic ticket (4) for a mobile terminal (T) which is associated with a security element (C_SE, SIM), the method comprising the following steps: generation of an unsecured part (PNS, 4a) having the identification of a service (SID); generating a secret portion (4b, 4c) having a second key (4c, K_TO); characterized in that the secret portion (PS) is encrypted by a first key (K_SE) known to the security element (C_SE). 25
    [0006]
    6. A method of generating an electronic ticket (4) according to claim 5, characterized in that the second key (K TO) is generated by the steps of obtaining a master key; Generating the second key (K_TO) from the master key and the unencrypted part of the token (4a).
    [0007]
    7. Mobile terminal (T) with which is associated a security element (C_SE, SIM), able to manage a ticket (4), the ticket (4) comprising an unsecured part (4a) comprising the identification of a service (SID) and a secret part (4b, 4c) encrypted by a first key (K_SE) known from the security element (C_SE), said secret part (4b, 4c) comprising at least a second key (4c, K_TO), the ticket being provided to access the service (S) via an access control device (B), the terminal being characterized in that it comprises the following modules: a transmission module to the security (C_SE) of the second encrypted key (K_TO) and at least one verification datum (4b, random); a module for receiving at least one piece of data (K_TO, 4b, random) of the security element (C_SE); a transmission module (E4) of at least one piece of data (K_TO, 4b, random) to the access control device (B).
    [0008]
    8. Security element (C_SE, SIM) associated with a mobile terminal (T) able to make available to an access control device (B), via the mobile terminal (T), an electronic ticket (4). ) stored in the mobile terminal (T), the ticket (4) comprising a non-secret part (4a) comprising the identification of a service (SID) and a secret part (4b, 4c) encrypted by a first key (K_SE ) known from the security element (C_SE), said secret part (4b, 4c) comprising at least one second key (4c, K_TO), characterized in that it comprises the following 20 modules: a reception module (E10 ) data from the mobile (T) comprising at least: o the second key (4c, K_TO) of the secret part (PS) and o at least one verification data (4b, DS, random); A decryption module (E11, CPU ', M', APS) of the data received using the first key (K_SE) known from the security element (C_SE); an encryption module (E12, CPU ', M', APS) of received data (4b, random) using the second key (K_TO) decrypted; a transmission module (E13) of verification data (4b, random) encrypted to the mobile (T).
    [0009]
    9. Entity (6) generating tickets (7) adapted to generate electronic tickets for a mobile terminal (T) with which is associated a security element (C_SE, SIM), characterized in that it comprises the following modules: A module for generating an unclear part (PNS, 4a) comprising the identification of a service (SID, M1); a module for generating a secret part (4b, 4c) comprising a second key (4c, K_TO); An encryption module of the secret part by a first key (K_SE) known from the security element (C_SE).
    [0010]
    10. System (SYS) for providing a secure dematerialized ticket service to the user of a mobile terminal (T), this system comprising: an entity (7) for generating an electronic ticket (4) according to the claim 9; a mobile terminal according to claim 7; a security element associated with the mobile terminal according to claim 8.
    [0011]
    11. A computer program comprising code instructions for implementing the method of secure management of electronic tickets according to claim 1, when the latter is executed by a processor.
    [0012]
    A computer program having code instructions for implementing the ticket verification method according to claim 4, when executed by a processor.
    [0013]
    Computer program comprising code instructions for implementing the ticket generation method according to claim 5, when executed by a processor. 25
    类似技术:
    公开号 | 公开日 | 专利标题
    EP1004101B1|2002-02-27|Terminal and system for implementing secure electronic transactions
    EP0973318A1|2000-01-19|Process for remote paying, by means of a mobile radio telephone, the acquisition of a good and/or a service, and corresponding system and mobile radio telephone
    EP1867190B1|2009-08-19|Managing access to multimedia contents
    EP3189485A1|2017-07-12|Electronic ticket management
    FR2935572A1|2010-03-05|SECURE METHODS OF TRANSMITTING AND RECEIVING DATA BETWEEN TERMINALS COMPRISING NEAR FIELD COMMUNICATION MEANS, AND CORRESPONDING TERMINALS
    WO2007012583A1|2007-02-01|Method for controlling secure transactions using a single physical device, corresponding physical device, system and computer programme
    EP1867189A1|2007-12-19|Secure communication between a data processing device and a security module
    WO2016207715A1|2016-12-29|Secure management of electronic tokens in a cell phone
    EP3117641B1|2019-04-10|Method of controlling access to a reserve zone with control of the validity of an access entitlement installed in the memory of a mobile terminal
    WO2002097751A1|2002-12-05|Method and device for certification of a transaction
    FR3042894A1|2017-04-28|METHOD FOR SECURING TRANSACTION DATA PROCESSING, TERMINAL AND CORRESPONDING COMPUTER PROGRAM
    EP3095223B1|2022-03-16|Method of transmitting encrypted data, method of reception, devices and computer programs corresponding thereto
    EP3136283B1|2020-12-16|Device and method for securing commands exchanged between a terminal and an integrated circuit
    EP2911365B1|2017-08-02|Method and system for protecting transactions offered by a plurality of services between a mobile device of a user and an acceptance point
    EP2471237B1|2013-06-05|Mobile electronic device configured to establish secure wireless communication
    FR2932296A1|2009-12-11|METHODS AND DEVICE FOR ELECTRONIC ENTITIES FOR THE EXCHANGE AND USE OF RIGHTS
    WO2017005644A1|2017-01-12|Method and system for controlling access to a service via a mobile media without a trusted intermediary
    EP3446436A1|2019-02-27|Method for obtaining a security token by a mobile terminal
    EP3758322A1|2020-12-30|Method and system for generating encryption keys for transaction or connection data
    EP3371760A1|2018-09-12|Method for verifying identity during virtualization
    FR2980865A1|2013-04-05|CONTENT DISTRIBUTION METHOD, OBTAINING DEVICE AND CORRESPONDING COMPUTER PROGRAM
    FR3029723A1|2016-06-10|SECURED LIFE SECRET TRANSMISSION METHOD FOR REALIZING A TRANSACTION BETWEEN A MOBILE TERMINAL AND AN EQUIPMENT
    FR2884996A1|2006-10-27|Digital file transferring method for e.g. Internet, involves transferring security data in subscriber identity module and non sensible data from one terminal to another and connecting module to latter terminal for exploiting content rights
    同族专利:
    公开号 | 公开日
    WO2016207715A1|2016-12-29|
    FR3037754B1|2017-07-28|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    EP1439495A1|2003-01-17|2004-07-21|Siemens Aktiengesellschaft|Electronic ticket, system and method for issuing electronic tickets, and devices and methods for using and performing operations on electronic tickets|
    EP2151795A1|2008-08-08|2010-02-10|France Telecom|Secure electronic coupon delivery to mobile device|
    US20150038118A1|2012-02-27|2015-02-05|Morpho|Method for verifying the identity of a user of a communicating terminal and associated system|
    EP2800085A1|2013-05-02|2014-11-05|Giesecke & Devrient GmbH|Method and apparatus for transmission of visually encoded data|
    CN107944857A|2017-10-31|2018-04-20|阿里巴巴集团控股有限公司|A kind of method and device of paying riding fee|
    FR3073304B1|2017-11-03|2021-03-05|Thales Sa|PROCESS FOR LEGITIMING A TRANSPORTATION TICKET CARRIED BY A MOBILE TERMINAL, COMPUTER PROGRAM AND ASSOCIATED MOBILE TERMINAL|
    CN109756884B|2017-11-07|2021-06-22|中国电信股份有限公司|Method, device and system for batch configuration of communication card and terminal|
    法律状态:
    2016-05-24| PLFP| Fee payment|Year of fee payment: 2 |
    2016-12-23| PLSC| Search report ready|Effective date: 20161223 |
    2017-05-23| PLFP| Fee payment|Year of fee payment: 3 |
    2018-05-25| PLFP| Fee payment|Year of fee payment: 4 |
    2020-03-13| ST| Notification of lapse|Effective date: 20200206 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1555723A|FR3037754B1|2015-06-22|2015-06-22|SECURE MANAGEMENT OF ELECTRONIC TOKENS IN A MOBILE TELEPHONE|FR1555723A| FR3037754B1|2015-06-22|2015-06-22|SECURE MANAGEMENT OF ELECTRONIC TOKENS IN A MOBILE TELEPHONE|
    PCT/IB2016/000879| WO2016207715A1|2015-06-22|2016-06-24|Secure management of electronic tokens in a cell phone|
    [返回顶部]